Method, system, and apparatus for providing customer product support for a software program based upon states of program execution instability

ABSTRACT

A method and apparatus are provided for providing custom product support for a computer program based on levels of execution instability. The execution of a software program is monitored over a period of time to determine the execution stability of the program. Based upon the monitoring and upon one or more threshold levels of instability, the execution stability of the program is categorized. Based upon the categorization, custom program support may be provided for a user of the computer system executing the program. For instance, based on the categorization free or reduced fee product support may be provided.

BACKGROUND OF THE INVENTION

One of the most important stages in the software development cycle isthe debugging stage that occurs after a software product has beenshipped to customers. This stage is important because the actualexperiences of users of the software product may be utilized during thisstage to isolate program errors, identify frequently or infrequentlyused features, and to generally make the software product better andmore stable.

The main focus of analysis in the after-release debugging stage istypically to identify the program errors (also referred to herein as“bugs”) that occur most frequently. By identifying the most frequentlyoccurring bugs and fixing them, the usability experience of many userscan be improved. There is another category of analysis, however, thathas been generally unaddressed by previous after-release debuggingsystems. This category involves identifying computer systems that mostfrequently encounter problems during the execution of an applicationprogram. These problems may or may not include the program errors thatoccur most frequently amongst all users.

Statistics show that a small number of users experience a highpercentage of the total number of overall problems. Such problems mayinclude program crashes, program hangs, abrupt program terminations, andother types of abnormal program terminations. Application programs thatexhibit these types of problems are generally referred to herein asbeing “unstable” or having “program execution instability.” An unstableprogram can be particularly frustrating for the computer user thatfrequently encounters the problems while using the program.

Previous after-release debugging systems do not provide a way toidentify computer systems having the highest frequency of programexecution instability and therefore do not provide a mechanism for thesoftware developer to assist the user experiencing the problems.Accordingly, there is a need for a method, system, and apparatus foridentifying computer systems having a high frequency of programexecution instability and for providing custom product support to a userof such a computer system.

It is with respect to these considerations and others that the variousembodiments of the present invention have been made.

BRIEF SUMMARY OF THE INVENTION

In accordance with embodiments of the present invention, the above andother problems are solved by a method and apparatus for providing customproduct support for a computer program based on states of executioninstability. By identifying computer systems having varying levels ofprogram execution instability, custom product support can be provided tousers having the highest frequency of program execution errors. Becausethe provision of custom product support is based on categorizing intostates of program instability based on thresholds, the thresholds may beadjusted to provide custom product support to varying numbers of users.

According to one aspect of the invention, a method is provided forproviding custom product support for a software program based on statesof program execution instability. According to the method, the executionof a software program is monitored over a period of time to determinethe execution stability of the program. Based upon the monitoring andupon one or more threshold levels of instability, the executionstability of the program is categorized into a state. For instance, thestability of the program may be categorized as “fine,” “bad,” or “verybad.” Based upon the categorization, custom program support may beprovided for a user of the computer system executing the program. Forinstance, based on the categorization free or reduced fee productsupport may be provided. Alternatively, a user of the computer may bedirected to an information resource, such as a web page, that isdetermined based upon the state. Likewise, a diagnostic program may beexecuted to identify and repair problems with the computer system andthe application program based upon the categorization.

According to aspects of the method, monitoring the execution of thesoftware program over a period of time may be performed by generating asession entry in a log each time the program is executed. The sessionentry includes data identifying the program, the length of time theprogram was executed, and data indicating whether the program wasterminated normally or abnormally. An abnormal termination may include aprogram crash, a program hang (where the program continues executing,but appears unresponsive to the user), or any other type of abnormaltermination (such as if power was removed from the computer while theprogram was executing).

The execution stability of the program may be determined based upon ananalysis of the log. In particular, one or more statistics may begenerated that describe the execution stability of the program. Forinstance, the number of abnormal terminations per number of programexecutions may be computed. Similarly, the number of abnormalterminations per number of minutes of program execution may becalculated. Other types of statistics may also be generated.

In order to categorize the execution stability of the program into astate, one or more threshold levels of instability may be utilized. Thethreshold values may be stored at the computer system and may beperiodically updated from a server computer in a remote control file.The threshold values define the values that should be utilized tocategorize the stability of the program execution. The threshold valuesare compared to the statistics to categorize the stability of theprogram into the one or more states of program execution instability.The thresholds may be provided in the remote control file for differentversions of the program. The contents of the remote control file may beperiodically modified to change the threshold values.

The invention may be implemented as a computer process, a computingapparatus or system, or as an article of manufacture such as a computerprogram product or computer readable media. The computer program productmay be a computer storage media readable by a computer system andencoding a computer program of instructions for executing a computerprocess. The computer program product may also be a propagated signal ona carrier readable by a computing system and encoding a computer programof instructions for executing a computer process.

These and various other features, as well as advantages, whichcharacterize the embodiments of the present invention, will be apparentfrom a reading of the following detailed description and a review of theassociated drawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 is a network diagram illustrating aspects of a computer networkutilized to embody various aspects of the invention;

FIG. 2 is a computer system architecture diagram illustrating a computersystem utilized in and provided by the various embodiments of theinvention; and

FIGS. 3-7 are flow diagrams illustrating processes provided by andutilized in the various embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

Referring now to the drawings, in which like numerals represent likeelements, various aspects of the present invention will be described. Inparticular, FIG. 1 and the corresponding discussion are intended toprovide a brief, general description of a suitable computing environmentin which embodiments of the invention may be implemented. While theinvention will be described in the general context of program modulesthat execute in conjunction with program modules that run on anoperating system on a personal computer, those skilled in the art willrecognize that the invention may also be implemented in combination withother types of computer systems and program modules.

Generally, program modules include routines, programs, components, datastructures, and other types of structures that perform particular tasksor implement particular abstract data types. Moreover, those skilled inthe art will appreciate that the invention may be practiced with othercomputer system configurations, including hand-held devices,multiprocessor systems, microprocessor-based or programmable consumerelectronics, minicomputers, mainframe computers, and the like. Theinvention may also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network. In a distributed computingenvironment, program modules may be located in both local and remotememory storage devices. Referring now to the drawings, in which likenumerals represent like elements through the several figures, aspects ofthe present invention and the exemplary operating environment will bedescribed.

FIG. 1 shows an illustrative operating environment for variousembodiments of the present invention. As shown in FIG. 1, a clientcomputer 2 is utilized in the various embodiments of the invention. Theclient computer comprises a standard desktop or server computer that maybe used to execute one or more program modules. The client computer 2 isalso equipped with program modules for monitoring the execution ofapplication programs and for determining the execution stability of theprograms. The client computer 2 is also operative to classify thestability of the programs based on one or more threshold values and toprovide custom product support for the applications based on theclassification.

In order to classify the stability of the programs executing at theclient computer 2, the client computer 2 is also operative toperiodically receive a remote control file from an error reportingserver computer 10 operated by a developer of the software program. Theerror reporting server computer 10 comprises a conventional servercomputer maintained and accessible through a LAN or the internet 8. Theerror reporting server computer 10 is operated by a developer of anapplication program of interest. Additional details regarding thecontents and use of the remote control file will be provided below withrespect to FIGS. 2-7. A product support server computer 6 may also beoperated by the developer to provide custom product support. Forinstance, the product support server may provide web pages or otherinformation based upon the level of program instability a userexperiences.

Referring now to FIG. 2, an illustrative computer architecture for aclient computer 2 utilized in the various embodiments of the inventionwill be described. The computer architecture shown in FIG. 2 illustratesa conventional desktop or laptop computer, including a centralprocessing unit 5 (“CPU”), a system memory 7, including a random accessmemory 9 (“RAM”) and a read-only memory (“ROM”) 11, and a system bus 12that couples the memory to the CPU 5. A basic input/output systemcontaining the basic routines that help to transfer information betweenelements within the computer, such as during startup, is stored in theROM 11. The computer 2 further includes a mass storage device 14 forstoring an operating system 16, application programs 18, and otherprogram modules, which will be described in greater detail below.

The mass storage device 14 is connected to the CPU 5 through a massstorage controller (not shown) connected to the bus 12. The mass storagedevice 14 and its associated computer-readable media providenon-volatile storage for the computer 2. Although the description ofcomputer-readable media contained herein refers to a mass storagedevice, such as a hard disk or CD-ROM drive, it should be appreciated bythose skilled in the art that computer-readable media can be anyavailable media that can be accessed by the computer 2.

By way of example, and not limitation, computer-readable media maycomprise computer storage media and communication media. Computerstorage media includes volatile and non-volatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer-readable instructions, data structures,program modules or other data. Computer storage media includes, but isnot limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solidstate memory technology, CD-ROM, digital versatile disks (“DVD”), orother optical storage, magnetic cassettes, magnetic tape, magnetic diskstorage or other magnetic storage devices, or any other medium which canbe used to store the desired information and which can be accessed bythe computer 2.

According to various embodiments of the invention, the computer 2 mayoperate in a networked environment using logical connections to remotecomputers through a network 8, such as the internet. The client computer2 may connect to the network 8 through a network interface unit 20connected to the bus 12. It should be appreciated that the networkinterface unit 20 may also be utilized to connect to other types ofnetworks and remote computer systems. The computer 2 may also include aninput/output controller 22 for receiving and processing input from anumber of other devices, including a keyboard, mouse, or electronicstylus (not shown in FIG. 1). Similarly, an input/output controller 22may provide output to a display screen, a printer, or other type ofoutput device.

As mentioned briefly above, a number of program modules and data filesmay be stored in the mass storage device 14 and RAM 9 of the computer 2,including an operating system 16 suitable for controlling the operationof a networked personal computer, such as the WINDOWS XP operatingsystem from MICROSOFT CORPORATION of Redmond, Wash. The mass storagedevice 14 and RAM 9 may also store one or more program modules. Inparticular, the mass storage device 14 and the RAM 9 may store anapplication stability monitor program 24 for monitoring the executionstability of one or more of the application programs 18 and forproviding custom product support for the application programs 18 if theprogram becomes unstable beyond certain settable thresholds. Theapplication stability monitor 24 may be executed in response to theexecution of an exception handler 32 that is operative to catch andhandle program execution exceptions within the client computer 2. Theapplication stability monitor 24 may also be executed manually by a userof the client computer 2.

In order to monitor the stability of the application programs 18, theapplication stability monitor 24 utilizes the services of an eventservice 26. The event service 26 is a facility provided by the operatingsystem 26 for logging events occurring at the client computer 2 to anevent log 28. For instance, the event service 26 may logsecurity-related events (e.g. an unauthorized login attempt),system-related events (e.g. a disk drive experiencing failures), andapplication-related events. As will be described in greater detailbelow, events regarding the execution and failure of the applicationprograms 18 are recorded in the event log 28. In particular, a sessionentry may be generated in the event log 28 each time an applicationprogram is executed. The session entry includes data identifying theprogram, the length of time the program was executed, and dataindicating whether the program was terminated normally or abnormally. Anabnormal termination may include a program crash, a program hang (wherethe program continues executing, but appears unresponsive to the user),or any other type of abnormal termination (such as if power was removedfrom the computer while the program was executing).

As will be described in greater detail below, the event log 28 may beperiodically parsed and statistics generated that describe the stabilityof the application programs 18. The statistics may include data definingthe number of abnormal terminations per number of program executions,the number of abnormal terminations per number of minutes of programexecution may be calculated, or other types of statistics indicating thestability of the application programs 18.

Once the statistics have been generated, the execution stability of theprograms may be categorized into states based upon the statistics andone or more threshold values stored in a remote control file 36. Thethreshold values define various levels of program instability. Forexample, threshold values may be defined that categorize the executionof a program module as “fine,” “bad,” or “very bad.” According to oneembodiment of the invention, the “fine” threshold indicates that theapplication program is sufficiently stable that no action should betaken. The “bad” threshold indicates that the application program issomewhat unstable, but not unstable enough to warrant the provision offree or reduced fee product support to the user. The user may bedirected to diagnostics or other information. The “very bad” thresholdindicates that the application stability is so poor that free or reducedfee product support is warranted. It should be appreciated that morethan three thresholds may be defined and the definitions of thesethresholds may vary according to the software product and its developer.It should be appreciated that monitoring of the performance of theapplication program and the provision of custom support may be enabledby the developer of the application program on anapplication-by-application basis.

The contents of the remote control file 36 may be periodically updatedand transmitted to the client computer 2 from the error reporting servercomputer 10. The remote control file 36 may also store expiration datesfor each threshold defining a time after which the thresholds should notbe utilized. The remote control file 36 may also store applicationversion numbers for each of the thresholds. The application versionnumbers allow different thresholds to be assigned to different versionsof an application program that may be installed and in use at the clientcomputer 2. It should be appreciated that the remote control file 36 maystore other data and may be utilized to control the operation of theclient computer 2 in additional ways. More information regarding thecontent and use of the remote control file can be found in co-pendingU.S. patent application Ser. No. 10/304,282, which is entitled “Methodand System for Remotely Controlling the Reporting of Events Occurringwithin a Computer System” and which is expressly incorporated herein byreference.

Based upon the assigned threshold, custom program support may beprovided for a user of the computer system executing the program by theapplication stability monitor 24. For instance, based on thecategorization, the user may be directed to free or reduced fee productsupport. Alternatively, a user of the computer may be directed to aninformation resource, such as a web page, that is determined based uponthe categorization. Likewise, a diagnostic program 34 may be executed toidentify and repair problems with the computer system and theapplication program based upon the categorization.

According to embodiments of the invention, the operating system 16 isoperative to store data in a registry 30. The registry 30 is a centralhierarchical database utilized to store information necessary toconfigure the client computer 2 for one or more users, applications, andhardware devices. For instance, the registry 30 is operative to store a“last fix time” registry key that identifies the last time which arepair was made to the software components on the client computer by thediagnostics 34. The registry 30 is further operative to store a“diagnostic state” registry key that identifies the current user's priorinteractions with the application stability monitor 24. The possiblevalues for the diagnostic state registry key are “new” where the userhas not previously utilized the application stability monitor 24,“altered” where the diagnostics 34 were previously executed and changeswere made to the client computer 2, “identified” where the diagnostics34 were executed and it was determined that the problem causing theinstability is external to the application programs 18 (e.g. such as ahardware failure), and “help” where diagnostics were executed and theuser was directed to customer support in the form of a product supportspecialist (“PSS”). As will be described in greater detail below, thevalue of the “diagnostic state” registry key is utilized to determinehow a newly encountered problem should be handled for a user. Additionaldetails regarding creation of the event log 28, operation of theexception handler 32, and the operation of the application stabilitymonitor 24 will be provided in greater detail below with respect toFIGS. 3-7.

Referring now to FIG. 3, an illustrative routine 300 will be describedillustrating a process performed for creating records in the event log28. When reading the discussion of the routines presented herein, itshould be appreciated that the logical operations of various embodimentsof the present invention are implemented (1) as a sequence of computerimplemented acts or program modules running on a computing system and/or(2) as interconnected machine logic circuits or circuit modules withinthe computing system. The implementation is a matter of choice dependenton the performance requirements of the computing system implementing theinvention. Accordingly, the logical operations illustrated in FIGS. 3-7,and making up the embodiments of the present invention described hereinare referred to variously as operations, structural devices, acts ormodules. It will be recognized by one skilled in the art that theseoperations, structural devices, acts and modules may be implemented insoftware, in firmware, in special purpose digital logic, and anycombination thereof without deviating from the spirit and scope of thepresent invention as recited within the claims set forth herein.

The routine 300 begins at operation 302, where a determination is madeby the event service 26 as to whether one of the application program 18has been started. If an application program has not been started, theroutine 300 returns to decision operation 302, where anotherdetermination is made. If an application program has been started, theroutine 300 continues to operation 306, where the time the applicationwas started is stored in memory

From operation 306, the routine 300 continues to operation 308, wherethe event service 26 determines whether the application program wasexited normally, such as in response to a user request. If theapplication program exited normally, the routine 300 branches tooperation 310, where data is stored in memory indicating that theapplication exited normally. The routine 300 then continues to operation312, where the length of time the application executed during thesession is recorded to in memory. The routine 300 then continues fromoperation 312 to operation 304 where a new entry is created in the eventlog 28 for the current application session (“a session entry”). The datarecording in memory regarding the execution of the program is thenstored in the session entry. These operations may be performed within anexception handler. From operation 304, the routine 300 continues tooperation 320, where it ends.

If, at operation 308, the event service 26 determines that theapplication program did not terminate its execution normally, theroutine 300 continues from operation 308 to operation 314. At decisionoperation 314, a determination is made as to whether the applicationprogram has hung. A hung application is an application that appears tobe executing but is not responsive to user input. It should beappreciated that the determination as to whether a program has hung maybe may be the operating system or by another program. If the applicationappears to have hung, the routine 300 branches from operation 314 tooperation 316. If the application has not hung, the routine 300continues from operation 314 to decision operation 322. At decisionoperation 322, a determination is made as to whether the applicationprogram crashed. A program crash refers to the failure of a program toperform correctly, resulting in suspension of operation of the program.If a crash is detected at operation 322, the routine 300 branches tooperation 316. If a crash is not detected, the operation 300 continuesto operation 320, where it ends. It should be appreciated that in thecase of a program crash, the operating system can force a crashedapplication program to shut down automatically. In the case of a hungprogram, it is up to the user to notice that the program is hung and torestart the program.

At operation 316, data is written to memory indicating that the sessionended in either a crash or a hang, as appropriate. The routine 300 thencontinues to operation 318, where the length that the applicationexecuted before the crash or hang is recorded in memory. The routine 300then continues from operation 318 to operation 319, where the exceptionis handled by the operating system. Details regarding aspects of theoperation of the exception handler 32 are provided below with respect toFIG. 5. The routine 300 then continues to operation to operation 304where a new entry is created in the event log 28 for the currentapplication session. The data recording in memory regarding theexecution of the program is then stored in the session entry. Fromoperation 319, the routine 300 continues to operation 320, where itends.

Referring now to FIG. 4, details will be provided for a routine 400 forcompleting a session entry in the event log. According to embodiments ofthe invention, the routine 400 is executed on the client computer 2 atstartup to complete session entries in the event log 28 that may nothave been completed. Uncompleted session entries can occur, forinstance, if power is removed from the computer 2 while the applicationis executing, if a crash results in a crash to the operation system 16,or under any other circumstances where the type of termination andsession length cannot be written to the event log 28.

The routine 400 begins at operation 402, where a determination is madeas to whether the previous session entry is complete. If the sessionentry is complete, there is no need to perform any further processing onthe session entry. Accordingly, the routine 400 branches from operation402 to operation 412, where it ends, if the session entry is complete.If the session entry is not complete, the routine 400 continues tooperation 406, where an indication is made in the session entry that theapplication program terminated abnormally. The routine 400 thencontinues to operation 412, where it ends.

Referring now to FIG. 5, additional details regarding the operation ofthe exception handler 32 will be described. As discussed briefly above,the exception handler 32 is called following the abnormal termination ofan application program. It should be appreciated that the exceptionhandler 32 performs many more functions for catching and handlingexceptions than those shown in FIG. 5. Only those functions performed bythe exception handler relevant to a discussion of the operation of theapplication stability monitor 24 are shown in FIG. 5 and describedherein.

The routine 500 begins at operation 502, where a determination is madeas to whether a policy implemented at the client computer 2 or aregistry entry indicating that the user does not want to be botheredwith reporting prevents the execution of the application stabilitymonitor 24. If so, the routine 500 branches to operation 512, where itends. If not, the routine 500 continues to operation 504, where adetermination is made as to whether a user interface (“UI”) pesterthrottle prevents the application stability monitor 24 from executing.The UI pester throttle prevents the user from being bothered toofrequently with UI relating to application performance monitoring. Ifthe UI pester throttle blocks the execution of the application stabilitymonitor 24, the routine 500 branches to operation 512, where it ends.Otherwise, the routine 500 continues to operation 506, where adetermination is made as to whether an audit pester throttle blocks theexecution of the application stability monitor 24. The audit pesterthrottle keeps the application stability monitor 24 from executing toofrequently and impacting the performance of the client computer 2. Ifthe audit pester throttle does blocks the execution of the applicationstability monitor 24, the routine 50 branches to operation 512, where itends. Otherwise the routine 500 continues from operation 506 tooperation 508. Additional details regarding the operation of the UIpester throttle and the audit pester throttle can be found in co-pendingU.S. patent application Ser. No. 10/305,215, and entitled “Queued ModeTransmission of Event Reports” which is expressly incorporated herein byreference.

Referring now to FIG. 6, additional details regarding the operation ofthe application stability monitor 24 will be provided. In particular,the routine 600 will be described for executing the applicationstability monitor 24. The routine 600 begins at operation 602, where ananalysis of the event log 28 is performed. The event log 28 is analyzedto categorize the stability of the application program into a state ofstability. As discussed above, according to one embodiment of theinvention, the stability may be categorized as “fine,” “bad,” or “verybad.” An illustrative routine 700 for performing the event log analysisis described below with respect to FIG. 7.

From operation 602, the routine 600 continues to operation 604, where adetermination is made as to whether the stability of the applicationprogram was categorized as “fine” by the event log analysis. If thestability of the application program is “fine” the routine 600 branchesto operation 606 where a determination is made as to whether theapplication stability monitor 24 was started manually by a user. If theapplication stability monitor 24 was not started manually, the routine600 branches to operation 620, where it ends. If the applicationstability monitor 24 was started manually, the routine 600 continuesfrom operation 606 to operation 608. This allows a user to interact withthe application stability monitor 24 if they start the program manuallyeven where the stability of the program is “fine.”

If, at operation 604, it is determined that the stability of theapplication program was categorized as “bad” or “very bad” by the eventlog analysis, the routine 600 continues from operation 604 to operation608. At operation 608, the routine 600 branches to either operation 610,612, 614, 616, or 616 based on the users preview interactions with theapplication stability monitor, as defined by the current value of thediagnostic state registry key described above. If the value of thediagnostic state registry key is “new”, the routine 600 branches tooperation 610. This means that the user has no previously utilized theapplication stability monitor 24. Accordingly, a dialog box may bepresent to the user for executing the diagnostics 34. Depending upon theresult of the diagnostics, the value of the diagnostic state registrykey may be set to “help,” “altered,” or “identified.”

If the value of the diagnostics state registry key is “diagnosticsaltered,” the routine 600 branches from operation 608 to operation 612.This indicates that the diagnostics were executed previously and thatchanges were made to the configuration of the application program in anattempt to improve its stability. At this point, the user may bedirected to free or reduced fee product support for the product.Depending on the chosen course, the value of the diagnostic stateregistry key may be set to “help,” “altered,” or “identified.”

If the value of the diagnostics state registry key is “diagnosticsexternal,” the routine 600 branches to operation 614. This indicatesthat the diagnostics 34 were performed previously and a problem wasdetected other than the application program. In this case, the user isnot bothered with any user interface notices.

If the value of the diagnostics state registry key is “help,” theroutine 600 branches to operation 618. This indicates that the user haspreviously been provided with information for reduced fee or freeproduct support. The user may again be given this information. Forinstance, the user may be directed to a product support web site whereproduct support may be obtained. From operations 610, 612, 614, and 618,the routine 600 continues to operation 620, where it ends.

Turning now to FIG. 7, the routine 700 will be described for analyzingthe event log 28. The routine 700 begins at operation 700 where adetermination is made as to which threshold version to utilize. Asdiscussed above, the threshold values may be assigned a version numbercorresponding to versions of an application program on the clientcomputer 2. This allows different thresholds to be assigned to differentversions of the same application program. The threshold version to useis determined based on the version of the application program for whichan analysis is to be performed.

Once the version number of the application program has been identified,the routine 700 continues to operation 704, where a determination ismade as to whether threshold values are present in the remote controlfile 36 for the version of the application program. If no thresholdvalues exist for the version, the routine 700 branches to operation 722,where a threshold value of “fine” is returned. If, however, the properthreshold values do exist, then the routine 700 continues to operation706.

At operation 706, the proper time period of entries in the event logthat should be utilized in the session analysis is determined. The timeperiod may comprise the period of time between the current time and thelast time a repair was applied to the application program.Alternatively, if no repairs have been made, the time period maycomprise the time period between the current time and a preferred timewindow (30 days for instance). In this manner, the universe of logentries that are considered in the analysis may be limited.

From operation 706, the routine 700 continues to operation 708, where adetermination is made as to whether a statistically significant minimumnumber of sessions are present in the event log 28 for the computed timeperiod. If the requisite minimum number of sessions are not present, theroutine 700 branches to operation 722, where a threshold value of “fine”is returned. If the requisite minimum number of sessions exists, theroutine 700 continues from operation 708 to operation 710.

At operation 710, a number of statistics are generated based upon thecontents of the event log 28 for the time period and for the particularapplication program that describe the stability of the applicationprograms. For instance, a statistic may be generated based on the numberof abnormal terminations of the program per number of programexecutions. Another statistic that may be generated is based on thenumber of abnormal terminations per number of minutes of programexecution. Other types of statistics indicating the stability of theapplication program may also be generated based on the contents of theevent log 28 during the time period. It should be appreciated thatcertain statistics may be generated for individual applications and thatother statistics may be generated for groups of applications, such asapplication suites.

Once the statistics have been generated, the statistics are compared tothe threshold values contained in the remote control file 36. Based onthe comparison, the stability of the application program may becategorized as “fine,” “bad,” or “very bad.” Once the stability of theapplication program has been categorized, the routine 700 continues tooperation 712, where a determination is made as to whether the stabilityof the program has been categorized as very bad. If the stability hasnot been categorized as very bad, the routine 700 branches to operation714 where a determination is made as to whether the stability has beencategorized as bad. If the stability has been categorized as bad, theroutine 700 continues to operation 700 where the “bad” threshold isreturned. If the stability has not been categorized as “bad,” theroutine branches to operation 722, where “fine” is returned.

If, at operation 712, it is determined that the threshold has beencategorized as “very bad”, the routine 700 continues to operation 716.At operation 716, a determination is made as to whether the thresholdvalues have expired. As discussed briefly above, the thresholds mayinclude expiration dates. If the threshold values have expired, theroutine 700 branches to operation 720 where “bad” is returned. Otherwisethe routine 700 continues to operation 718, where “very bad” isreturned.

Based on the foregoing, it should be appreciated that the variousembodiments of the invention include a method, system, apparatus, andcomputer-readable medium for providing custom product support for acomputer program based on levels of execution instability. The abovespecification, examples and data provide a complete description of themanufacture and use of the composition of the invention. Since manyembodiments of the invention can be made without departing from thespirit and scope of the invention, the invention resides in the claimshereinafter appended.

1. A method for providing custom product support for a software programbased on states of program execution instability, the method comprising:monitoring the execution of the software program over a period of timeto determine the execution stability of the program; categorizing theexecution stability of the program based on one or more threshold levelsof instability; and providing custom product support for the softwareprogram based upon the categorization.
 2. The method of claim 1, whereinmonitoring the execution of the software program over a period of timecomprises: generating a session entry in a log each time the program isexecuted, the session entry comprising data identifying the program, thelength of time the program was executed, and indicating whether theexecution of the program was terminated normally or abnormally.
 3. Themethod of claim 2, wherein an abnormal termination comprises either aprogram crash, a program hang, or an abnormal program termination. 4.The method of claim 3, wherein determining the execution stability ofthe program comprises analyzing the log to generate one or morestatistics that describe the execution stability of the program.
 5. Themethod of claim 4, wherein the statistics comprise the number ofabnormal terminations per number of program executions.
 6. The method ofclaim 5, wherein the statistics further comprise the number of abnormalterminations per number of minutes of program execution.
 7. The methodof claim 6, wherein categorizing the execution stability of the programbased on one or more threshold levels of instability comprises:periodically receiving a remote control file, the remote control filecontaining data identifying one or more thresholds of program executioninstability; and comparing each of the statistics to a correspondingthreshold to categorize the execution instability of the program intoone of a plurality of states of program execution instability.
 8. Themethod of claim 7, wherein the remote control file contains dataidentifying one or more thresholds of program execution instability forone or more versions of the program, and wherein the method furthercomprises determining whether the remote control file containsthresholds for the version of the program prior to categorizing theexecution stability of the program.
 9. The method of claim 8, whereinproviding custom product support for the software program comprisesdirecting a user of the computer program to an information resourcehaving free or reduced fee product support for the software programbased upon the categorization.
 10. The method of claim 8, whereinproviding custom product support for the software program comprisesdirecting a user of the computer program to an information resourceidentified based upon the categorization.
 11. The method of claim 8,wherein providing custom product support for the software programcomprises executing a diagnostic program based upon the categorization.12. A system for providing custom product support for a software programbased on threshold levels of program execution instability, the systemcomprising: a client computer operative to receive a remote control filefrom a server computer containing data identifying one or morethresholds of program execution instability for one or more versions ofthe software program, to monitor the execution of a software programover a period of time to determine the execution stability of theprogram, to categorize the execution stability of the program based onthe thresholds of program execution instability contained in the remotecontrol file, and to provide custom product support for the softwareprogram based upon the categorization.
 13. The system of claim 12,wherein monitoring the execution of the software program over a periodof time comprises: generating a session entry in a log stored at theclient computer each time the program is executed, the session entrycomprising data identifying the program, the length of time the programwas executed, and indicating whether the execution of the program wasterminated normally or abnormally.
 14. The system of claim 13, whereinan abnormal termination comprises either a program crash, a programhang, or an abnormal program termination.
 15. The system of claim 14,wherein determining the execution stability of the program comprisesanalyzing the log at the client computer to generate one or morestatistics that describe the execution stability of the program.
 15. Thesystem of claim 14, wherein the statistics comprise the number ofabnormal terminations per number of program executions.
 16. The systemof claim 15, wherein the statistics further comprise the number ofabnormal terminations per number of minutes of program execution. 17.The system of claim 16, wherein categorizing the execution stability ofthe program based on one or more threshold levels of instabilitycomprises comparing each of the statistics to a corresponding thresholdto categorize the execution instability of the program into one of aplurality of states of program execution instability.
 18. The system ofclaim 16, wherein providing custom product support for the softwareprogram comprises directing a user to an information resource providingfree or reduced fee product support depending on the level of programexecution instability.
 19. The system of claim 16, wherein providingcustom product support for the software program comprises directing auser of the client computer to an information resource, the informationresource determined based on the level of program execution instability.20. The system of claim 16, wherein providing custom product support forthe software program comprises executing a diagnostic program on theclient computer to diagnose problems with the program.
 21. Acomputer-readable medium having computer executable instructions storedthereon which, when executed by a computer, cause the computer to:monitor the execution of the software program over a period of time todetermine the execution stability of the program; categorize theexecution stability of the program based on one or more threshold levelsof instability; and provide custom product support for the softwareprogram based upon the categorization.
 22. The computer-readable mediumof claim 21, wherein monitoring the execution of the software programover a period of time comprises: generating a session entry in a logeach time the program is executed, the session entry comprising dataidentifying the program, the length of time the program was executed,and indicating whether the execution of the program was terminatednormally or abnormally.
 23. The computer-readable medium of claim 22,wherein an abnormal termination comprises either a program crash, aprogram hang, or an abnormal program termination.
 24. Thecomputer-readable medium of claim 23, wherein determining the executionstability of the program comprises analyzing the log to generate one ormore statistics that describe the execution stability of the program.25. The computer-readable medium of claim 24, wherein the statisticscomprise the number of abnormal terminations per number of programexecutions.